Process and system for sharing program fragments

ABSTRACT

A technique for sharing code fragments involves detecting identical code fragments, then replacing code fragments with references to an identical code fragment. A process according to the technique may include detecting identical code fragments in one or more modules, presenting at runtime a single code fragment that is identical to the identical code fragments, and automatically sharing the single code fragment among the one or more modules. A system according to the technique may include a code fragments database that may includes code fragments and a code server configured to receive requests for a program and provide references to one or more of the code fragments in the code fragments database. Another system according to the technique may include a first object, a second object, and a method object, wherein a reference associated with a first method of the first object and the reference associated with a second method of the second object are pointers to the method object.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.10/991,444, filed Nov. 17, 2004, which is a Continuation of U.S. patentapplication Ser. No. 10/016,794, filed Oct. 29, 2001, which claimspriority from U.S. Provisional Patent Application No. 60/255,096, filedDec. 13, 2000, and U.S. Provisional Patent Application No. 60/555,774,filed Mar. 23, 2004, all of which are being incorporated herein.

BACKGROUND

The present invention relates to computer memory management. Moreparticularly, the present invention relates to linking softwarecomponents.

Embedded devices are often memory-constrained. Adding functionality toan embedded device means using memory to store the code necessary forthe functionality. Thus, embedded device vendors have to balancefunctionality versus memory usage, and often have to leave outfunctionality to be able to fit the program in available memory.

Embedded devices may also be able to dynamically obtain newfunctionality in the form of program code over a network connection.Sending such code over the network connection requires network bandwidthin proportion with the amount of code that must be transferred to obtainthe new functionality.

Program code may be referred to as comprising many “code fragments,”often structured as methods that can be invoked. Some programminglanguages, such as, for example, Java™, support method-sized codefragments. Other programming languages, such as Smalltalk, supportsmaller code fragments called “blocks,” where each method may containseveral blocks. This functionality is described in Smalltalk-80: TheLanguage and Its Implementation by Adele Goldberg and David-Robson(Addison-Wesley, 1984), which is incorporated herein by reference.

FIG. 1 depicts a conceptual view 100 of compiling source code andrepresenting the source code as runnable code. As shown in theconceptual view 100, source code 102 and 104 is compiled into respectiveobjects 112 and 114. The objects 112 and 114 include respective virtualmachine instructions 122 and 124. In the example of FIG. 1, the VMinstructions 122 and 124 are identical, though the source code 102 and104 is not. It may be noted that the smaller a code fragment, the largerthe possibility that another code fragment identical to the first codefragment is already present on the device.

It may be beneficial to reuse identical code fragments, such that onlyone copy of the code exists on the device. Moreover, it may bebeneficial to know in advance what code fragments exist on a device, sothat such code fragments need not be transmitted when uploading newfunctionality to the device.

Known techniques allow limited sharing of similar code between programs.For example, some development tools enable developers to place methodsin shared libraries. A dynamic linker ensures that only one copy of theshared library exists, and that the copy is shared by the programs thatuse the methods in the library. Shared libraries are common in modernoperating systems, such as Microsoft® Windows™ where they are known asDynamic Link Libraries, as described in Programming Windows® (5^(th)Edition) by Charles Petzold (Microsoft Press, 1998), which isincorporated herein by reference.

Developers of shared libraries typically must anticipate what codefragments others might be interested in reusing. Moreover, sharedlibraries typically require that other developers know that the sharedlibrary contains the code fragments they need. In other words, bothparties must explicitly state their intent to share code fragments.

Another technique for sharing code fragments is the use ofobject-oriented programming. Object-oriented programming supportssharing through inheritance, as described in On the Notion ofInheritance by Antero Taivalsaari (ACM Computing Surveys, Vol. 28, No.3, 1996), which is incorporated herein by reference. Using inheritance,a developer can create a subclass of an already existing class andthereby inherit (share) its methods. Inheritance allows developers tostructure their programs for sharing, since shared behavior andinheritance relationships are an integral part of the object-orientedprogram design process.

Sharing through inheritance is used in object-oriented platforms such asJava™. A Java™ virtual machine (VM) is responsible for running the codethat ensures that for each shared method, only one copy of the methodexists, as described in The Java™ Virtual Machine Specification (2^(nd)Edition) by Tim Lindholm and Frank Yellin (Addison-Wesley, 1999), whichis incorporated herein by reference.

These sharing techniques require that developers design programs withsharing in mind. Either the code must be put in a separate sharedlibrary or in a superclass of the classes that use the shared code.These sharing techniques do not address the issue of two otherwiseunrelated code fragments being identical. For example, two differentmethods may, when translated from source code into runnable code, end upbeing identical (i.e., containing semantically equivalent code, such asthe same instructions). This is especially likely for small methods,even if the methods are written in different programming languages.However, the developers might not be aware that the methods are, infact, identical. Since prior art techniques require that developers beaware of and explicitly state an intention to share, two methods havingthe same functionality could exist in memory at runtime.

SUMMARY

A technique for sharing code fragments involves detecting identical codefragments, then replacing code fragments with references to an identicalcode fragment. In an embodiment, a process according to the techniquemay include detecting identical code fragments in one or more modules,presenting at runtime a single code fragment that is identical to theidentical code fragments, and automatically sharing the single codefragment among the one or more modules.

In another embodiment, the modules may include objects. In anotherembodiment, detecting the identical code fragments may include analyzingrunnable code. In another embodiment, automatically sharing the singlecode fragment may include sharing a complete method. In anotherembodiment, automatically sharing the single code fragment may includesharing a block. In another embodiment, automatically sharing the singlecode fragment may involve referencing the single code fragment usingpointers.

In another embodiment, the single code fragment may include a methodobject, and automatically sharing the single code fragment may includepointing objects associated with each of the identical code fragments tothe method object. In another embodiment, detecting identical codefragments, presenting the single code fragment at runtime, andautomatically sharing the single code fragment occur sequentiallywithout user involvement.

In another embodiment, the process also may include receiving new codefrom a server, determining whether the single code fragment is identicalto a code fragment in the new code, replacing the code fragment in thenew code with a reference to the single code fragment if it isdetermined that the single code fragment is identical to the codefragment in the new code, and saving the code fragment in the new codefor comparison against code fragments from future new codes if it isdetermined that the single code fragment is not identical to the codefragment in the new code.

In another embodiment, the process also may include maintaining a listof first code fragments, including the single code fragment, in a codefragment database, introducing a set of second code fragments, each ofwhich are identical to a code fragment in the code fragment database,and a set of third code fragments, none of which are identical to a codefragment in the code fragment database. The introducing may be bysubstituting a reference to one of the first code fragments for each ofthe set of second code fragments and adding each of the set of thirdcode fragments to the code fragment database. In another embodiment, theprocess also may include dynamically uploading code at runtime.

In another embodiment, the process may include writing source code of aprogram in a programming language, translating the source code intorunnable code, and providing the runnable code as at least one module ofthe one or more modules. In this embodiment executing the runnable codemay include executing the runnable code using a virtual machine.

In an embodiment, a system made according to the technique may include acode fragments database that may include a plurality of code fragmentsand a code server configured to receive requests for a program andprovide references to one or more of the plurality of code fragments inthe code fragments database, wherein the one or more of the plurality ofcode fragments may be associated with the requested program.

In an embodiment, the code server may further be configured to detectidentical code fragments in one or more objects. In another embodiment,the code server may further be configured to download the program andupdate the code fragments database in accordance with code fragments inthe program. In another embodiment, the code server may further beconfigured to build and maintain the code fragments database.

In another embodiment, the system may include a developer I/O moduleconfigured to provide new code fragments to the code server, wherein thecode server is further configured to update the code fragment databaseaccording to the new code fragments.

Another system made according to the technique may include a firstobject, including a reference associated with a first named method, asecond object, including a reference associated with a second namedmethod, and a method object, wherein the reference associated with thefirst named method and the reference associated with the second namedmethod are pointers to the method object. In an embodiment, the firstobject and the second object may be associated with different classes.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated in the figures. However,the embodiments and figures are illustrative rather than limiting; theyprovide examples of the invention.

FIG. 1 (prior art) depicts a conceptual view of compiling source codeand representing the source code as runnable code.

FIG. 2 depicts a conceptual view of compiling source code andrepresenting the source code as runnable code according to anembodiment.

FIG. 3 depicts a system for provisioning a client with programsaccording to an embodiment.

FIG. 4 depicts a system for provisioning a client with programsaccording to another embodiment.

FIG. 5 depicts a system for provisioning a client with programsaccording to another embodiment.

FIGS. 6A, 6B, and 6C depict systems that include a client system with adeveloper environment according to an embodiment.

FIG. 7 depicts a networked system for use in an embodiment.

FIG. 8 depicts a computer system for use in the system of FIG. 7.

FIGS. 9A, 9B, 9C, and 9D depict flowcharts according to embodiments.

DETAILED DESCRIPTION

FIG. 1 (prior art) is described above in the background section of thespecification.

FIG. 2 depicts a conceptual view 200 of compiling source code andrepresenting the source code as runnable code according to anembodiment. The conceptual view 200 includes source code 202, sourcecode 204, an object 212, and object 214, a method object 220, a pointer222, and a pointer 224.

In the example of FIG. 2, the source code 202 and the source code 204 iswritten in C++. However, any programming language, including Java™,could be used. Indeed, the source code 202 and the source code 204 maybe written in different languages. Advantageously, in an embodiment,code fragments are analyzed post-compilation as runnable code, whichtypically makes the specific language in which the code is writtenirrelevant. Moreover, even in a single programming language, there maybe multiple ways to express the same instructions. For example, twosource code fragments with different source code text may besemantically equivalent and, accordingly, compile into identicalrunnable code fragments.

The source code 202 is translated into the object 212 and the sourcecode 204 is translated into the object 214. The translation may be byway of, for example, a compiler. As is known in the art of computerprogramming, a compiler may create runnable code that is executable by acomputer. For example, the runnable code may be executable by computerhardware associated with the computer. Alternatively, the runnable codemay be executed by an interpreter, such as is included in, for example,a Java™ Virtual Machine (VM).

In the example of FIG. 2, the object 212 is represented as a set of datafields, one of which includes the pointer 222. Similarly, the object 214is represented as a set of data fields, one of which includes thepointer 224. Additional pointers (not shown) may be included in datafields, as well. In an alternative, the system need not be implementedin an object-oriented fashion. In this alternative, the object 212 andthe object 214 may simply be implemented as a non-object data structurewith data fields.

In the example of FIG. 2, the method object 220 is represented as avirtual machine (VM) instruction set. As is known in the art of computerprogramming, there are multiple possible representations of theinstruction set, including machine language or assembly language. Forillustrative purposes, FIG. 2 depicts a VM instruction set.

In VM systems, the code for methods is often stored in method objects,such as the method object 220. Typically, method objects include, inaddition to the code, information such as the name of the method and theclass in which the method is defined. Since, in an embodiment, methodobjects are shared regardless of, for example, the method name, the nameis not always necessary. Indeed, the method object 220, in anembodiment, includes only runnable code.

Since, in the example of FIG. 2, a code fragment associated with thesource code 202 and 204 is semantically equivalent and the VMinstruction set is, accordingly, identical, the pointers 222 and 224 maybe used to point to the same instruction set. In the example of FIG. 2,the semantically equivalent portion of the source code 202 and thesource code 204 is the portion of the code that adds one to the firstfield of the object invoked on. In other words, “x=x+1” and “day:=day+1” are semantically equivalent. Both of these instructions may beassociated with the instruction set depicted in the method object 220,which encapsulates the instruction set.

Notably, the source code 202 and the source code 204 do not include codethat is specifically directed to sharing the method object 220.Advantageously, in an embodiment, static specification of which codefragments to share is not required.

FIG. 3 depicts a system 300 for provisioning a client with programsaccording to an embodiment. The system 300 includes source code programs302-1 to 302-N (referred to collectively hereinafter as the source codeprograms 302), a compilation module 306, a programs database 308, aserver 310, and a client 320.

In the example of FIG. 3, the source code programs 302 may be written inone or more programming languages. The compilation module 306 mayconvert the source code programs 302 into runnable code. The source codeprograms 302 may be created at any time and in any location prior tocompilation by the compilation module 306. Thus, for example, editorsoftware may be implemented on a first computer, facilitatingdevelopment of source code by a developer. Some time later, the sourcecode could be provided to a second computer on which the compilationmodule 306 is implemented. Alternatively, the source code programs 302could be developed on a computer that includes a compiler, and compiledinto runnable code.

The output of the compilation module 306 is runnable code, which may belogically divided into code fragments. These code fragments mayrepresent blocks, methods, or some other logical division. The codefragments are stored in the programs database 308. It may be noted thatthe code fragments may be stored as computer programs that do not shareidentical code fragments. The sharing of identical code fragments maycome later at the client 320, for example. Or perhaps, the sharing ofidentical code fragments is static in the programs database 308 anddynamic sharing comes later at the client 320. For example, programs inthe programs database 308 may share code fragments using a sharedlibrary.

The compilation module 306 and the programs database 308 need not belocal to one another. In addition, the compilation module 306 maycompile source code programs 302 into runnable code well in advance ofbeing added to the programs database 308. For example, a computerprogram could be written as source code on a computer, then compiledinto runnable code (e.g., a Java™ bytecode sequence). Much later, therunnable code could be added to the programs database 308.

In the example of FIG. 3, the server 310 provides code fragments fromthe programs database 308 to the client 320. The code fragments may beprovided when a program is requested, specific code fragments arerequested, or a subset of code fragments associated with a program maybe provided (e.g., some code fragments may not be sent because theserver knows the code fragments are already present on the client 320).The programs database 308 need not be local to the server 310 (e.g., theserver 310 could be a proxy server that must request data from theprograms database 308). Moreover, the server 310 need not be local tothe client 320. Indeed, it is quite common for servers to be remote withrespect to clients, as is well known in the art of computer networking.

Some examples of the provisioning of code fragments to a clientaccording to embodiments are described with reference to FIGS. 4-6. FIG.4 depicts a system 400 for provisioning a client with programs accordingto an embodiment. The system 400 includes a programs database 408, aserver 410, and a system 420. The system 420 includes a client 422 and acode fragment database 424. The programs database 408 and server 410 maybe similar to the programs database 308 and server 310 (FIG. 3).

FIG. 4 is intended to depict an example wherein the client 422 downloadscomplete programs and then automatically alters the programs accordingto techniques described herein. This example has the advantage offacilitating the downloading of files from any compatible prior artserver, regardless of whether the server is aware of the code fragmentsdatabase 424 or related functionality.

In operation, the server 410 provides program code fragments from theprograms database 408 to the client 422. In an embodiment, the server410 is an HTTP server and the programs database 408 is a file structurethat includes programs. In an embodiment, the system 420 is remote withrespect to the server 410 and the client 422 downloads code fragmentsfrom the server 410 across a network, such as a LAN or WAN, or theInternet.

In operation, in an embodiment, when the client 422 receives thedownloaded program code fragments, the client 422 compares each (or asubset of) the code fragments with a code fragments database 424. Thecomparison may be made by comparing, for example, a sequence ofinstructions with sequences of instructions that have been stored in thecode fragments database 424. If a code fragment matches an entry in thecode fragments database 424, then the code fragment is discarded. If acode fragment does not match an entry in the code fragments database424, then an entry associated with the code fragment is added to thecode fragments database 424.

In operation, after code fragments have been entered, if necessary, intothe code fragments database 424, the data field that would have includeda code fragment instead includes a pointer to the relevant code fragmentin the code fragments database 424. In this way, identical codefragments can be shared by programs that point to the same code fragmententry.

FIG. 5 depicts a system 500 for provisioning a client with programsaccording to another embodiment. FIG. 5 is intended to depict an examplewherein bandwidth required for the download of a program is reduced. Thesystem 500 includes a programs database 508, a server 510, a codefragment selection interface 516, and a system 520. The programsdatabase 508 and server 510 may be similar to the programs database 308and server 310 (FIG. 3). The code fragments selection interface 516allows for selective download of code fragments associated with aprogram. The system 520 includes a client 522, a code server 524, and acode fragments database 526.

The code fragment selection interface 516 may not be available on allserver systems. However, if the server 510 is implemented in anenterprise system, such as a LAN or WAN, the server may serve manysystems or workstations. In this case, the enterprise may provide thecode fragment selection interface 516 to reduce network bandwidthrequirements when downloading from the server 510. Bandwidthrequirements are reduced because a request for a program includesinformation related to code fragments that are already present at therequesting system. For example, if the system 520 requests a programthat contains identical code fragments, the code fragment selectioninterface 516 may just serve one of the identical code fragments (andinclude a reference or other identifier in place of the code fragmentsthat were not served). Alternatively, the code fragments selectioninterface may have access to a database related to what programs are on,for example, the system 520. In this alternative, the server 510 neednot serve code fragments that already exist on the system 520, furtherreducing the bandwidth requirements associated with the download of aprogram.

In operation, in an embodiment, the client 522 requests from the codeserver 524 code fragments associated with a program. For example, theclient 522 may request a program. The code server 524 checks the codefragments database 526 to determine whether any of the requested codefragments are locally available. If not, the code server 524 downloadsthe code fragments from the server 510. The code server 524 then addsthe code fragments to the code fragments database 526 and answers therequest for the code fragments from the client 522. The client 522 thenreferences the code fragments from the code fragments database 526using, for example, a pointer.

FIGS. 6A, 6B, and 6C depict systems that include a client system with adeveloper environment according to an embodiment. FIG. 6A depicts asystem 600A in which a code server maintains a code fragment database.The system 600A includes an optional server 610 and a client system 620.The server 610 is optional because it is not used in the example of FIG.6A and because the system 600A could be implemented without the server610. The server 610 may be similar to the server 310 (FIG. 3). Theclient system 620 includes a runtime client 622, a code server 624, acode fragment database 626, and an optional developer I/O module 628.The developer I/O module 628 is optional because it is not used in theexample of FIG. 6A and because the system 600A could be implementedwithout the developer I/O module 628.

In operation, in an embodiment, the code server 624 requests codefragments from the runtime client 622. The runtime client 622 returnsthe code fragments to the code server 624. In an embodiment, the codefragments may be obtained from any program on the runtime client 622. Inanother embodiment, the code fragments may be obtained from runtimeobjects or method objects. The code server uses the code fragments tobuild and maintain the code fragment database 626. In this way, the codefragment database 626 includes a representation of at least some of thecode fragments on the runtime client 622.

FIG. 6B depicts a system 600B in which a code server maintains a codefragment database. The system 600B includes components that are similarto those of the system 600A. FIG. 6B is intended to illustrateoperations that are possible in a system that includes a code fragmentdatabase 626. An example of building the code fragment database 626 wasprovided with reference to FIG. 6A (and it is assumed, for the purposesof example, that the code fragment database 626 includes arepresentation of at least some of the code fragments on the runtimeclient 622).

In operation, in an embodiment, the runtime client 622 requests adownload of a program from the code server 624. The code server 624 maydownload the requested program from the server 610. It may be notedthat, in an alternative embodiment, a subset of the code fragmentsassociated with the program may be downloaded (see, e.g., FIG. 5).

In an embodiment, after downloading some or all of the program, the codeserver 624 adds new code fragments to the code fragment database 626. Ifthe code fragment database 626 has identical code, then the downloadedcode fragment is not new and may be discarded and replaced with apointer to the identical code fragment in the code fragment database626. The code server 624 may then upload to the runtime client 622references to the code fragments. In an alternative, if a code fragmentis not identical to any other code fragment, the code fragment itselfmay be uploaded to the runtime client 622.

FIG. 6C depicts a system 600C in which a developer can modify codefragments. The system 600C includes components that are similar to thoseof the system 600A. FIG. 6C is intended to illustrate a system in whicha code server is integrated into a development environment, allowing adeveloper to dynamically upload code to and change code on a runningsystem from within the development environment.

In an embodiment, a developer who may or may not be monitoring thesystem 620 may change, delete, or add code fragments “on the fly” duringruntime. The developer interacts with the system 620 through thedeveloper I/O module 628. In operation, in an embodiment, the developerI/O module 628 provides new code fragments to the code server 624. Thecode server 624 updates the code fragments database 626 with the newcode fragments. The code server 624 then uploads references to the newcode fragments to the runtime client 622. The references may replacereferences in the runtime client 622. Alternatively, the code fragmentto which a reference points could be modified without changing thereference.

The following description of FIGS. 7 and 8 is intended to provide anoverview of computer hardware and other operating components suitablefor performing the methods of the invention described herein, but is notintended to limit the applicable environments. Similarly, the computerhardware and other operating components may be suitable as part of theapparatuses of the invention described herein. The invention can bepracticed with other computer system configurations, including hand-helddevices, multiprocessor systems, microprocessor-based or programmableconsumer electronics, network PCs, minicomputers, mainframe computers,and the like. The invention can also be practiced in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network.

FIG. 7 depicts a networked system 700 that includes several computersystems coupled together through a network 702, such as the Internet.The term “Internet” as used herein refers to a network of networks whichuses certain protocols, such as the TCP/IP protocol, and possibly otherprotocols such as the hypertext transfer protocol (HTTP) for hypertextmarkup language (HTML) documents that make up the World Wide Web (theweb). The physical connections of the Internet and the protocols andcommunication procedures of the Internet are well known to those ofskill in the art.

The web server 704 is typically at least one computer system whichoperates as a server computer system and is configured to operate withthe protocols of the world wide web and is coupled to the Internet. Theweb server system 704 can be a conventional server computer system.Optionally, the web server 704 can be part of an ISP which providesaccess to the Internet for client systems. The web server 704 is showncoupled to the server computer system 706 which itself is coupled to webcontent 708, which can be considered a form of a media database. Whiletwo computer systems 704 and 706 are shown in FIG. 7, the web serversystem 704 and the server computer system 706 can be one computer systemhaving different software components providing the web serverfunctionality and the server functionality provided by the servercomputer system 706, which will be described further below.

Access to the network 702 is typically provided by Internet serviceproviders (ISPs), such as the ISPs 710 and 716. Users on client systems,such as client computer systems 712, 718, 722, and 726 obtain access tothe Internet through the ISPs 710 and 716. Access to the Internet allowsusers of the client computer systems to exchange information, receiveand send e-mails, and view documents, such as documents which have beenprepared in the HTML format. These documents are often provided by webservers, such as web server 704, which are referred to as being “on” theInternet. Often these web servers are provided by the ISPs, such as ISP710, although a computer system can be set up and connected to theInternet without that system also being an ISP.

Client computer systems 712, 718, 722, and 726 can each, with theappropriate web browsing software, view HTML pages provided by the webserver 704. The ISP 710 provides Internet connectivity to the clientcomputer system 712 through the modem interface 714, which can beconsidered part of the client computer system 712. The client computersystem can be a personal computer system, a network computer, a web TVsystem, or other computer system. While FIG. 7 shows the modem interface714 generically as a “modem,” the interface can be an analog modem, isdnmodem, cable modem, satellite transmission interface (e.g. “direct PC”),or other interface for coupling a computer system to other computersystems.

Similar to the ISP 714, the ISP 716 provides Internet connectivity forclient systems 718, 722, and 726, although as shown in FIG. 7, theconnections are not the same for these three computer systems. Clientcomputer system 718 is coupled through a modem interface 720 whileclient computer systems 722 and 726 are part of a LAN 730.

Client computer systems 722 and 726 are coupled to the LAN 730 throughnetwork interfaces 724 and 728, which can be ethernet network or othernetwork interfaces. The LAN 730 is also coupled to a gateway computersystem 732 which can provide firewall and other Internet-relatedservices for the local area network. This gateway computer system 732 iscoupled to the ISP 716 to provide Internet connectivity to the clientcomputer systems 722 and 726. The gateway computer system 732 can be aconventional server computer system.

Alternatively, a server computer system 734 can be directly coupled tothe LAN 730 through a network interface 736 to provide files 738 andother services to the clients 722 and 726, without the need to connectto the Internet through the gateway system 732.

FIG. 8 depicts a computer system 740 for use in the system 700 (FIG. 7).The computer system 740 may be a conventional computer system that canbe used as a client computer system or a server computer system or as aweb server system. Such a computer system can be used to perform many ofthe functions of an Internet service provider, such as ISP 710 (FIG. 7).

In the example of FIG. 8, the computer system 740 includes a computer742, I/O devices 744, and a display device 746. The computer 742includes a processor 748, a communications interface 750, memory 752,display controller 754, non-volatile storage 756, and I/O controller758. The computer system 740 may be couple to or include the I/O devices744 and display device 746.

The computer 742 interfaces to external systems through thecommunications interface 750, which may include a modem or networkinterface. It will be appreciated that the communications interface 750can be considered to be part of the computer system 740 or a part of thecomputer 742. The communications interface can be an analog modem, ISDNmodem, cable modem, token ring interface, satellite transmissioninterface (e.g. “direct PC”), or other interfaces for coupling acomputer system to other computer systems.

The processor 748 may be, for example, a conventional microprocessorsuch as an Intel Pentium microprocessor or Motorola power PCmicroprocessor. The memory 752 is coupled to the processor 748 by a bus760. The memory 752 can be dynamic random access memory (DRAM) and canalso include static ram (SRAM). The bus 760 couples the processor 748 tothe memory 752, also to the non-volatile storage 756, to the displaycontroller 754, and to the I/O controller 758.

The I/O devices 744 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. The display controller 754 may control in theconventional manner a display on the display device 746, which can be,for example, a cathode ray tube (CRT) or liquid crystal display (LCD).The display controller 754 and the I/O controller 758 can be implementedwith conventional well known technology.

The non-volatile storage 756 is often a magnetic hard disk, an opticaldisk, or another form of storage for large amounts of data. Some of thisdata is often written, by a direct memory access process, into memory752 during execution of software in the computer 742. One of skill inthe art will immediately recognize that the terms “machine-readablemedium” or “computer-readable medium” includes any type of storagedevice that is accessible by the processor 748 and also encompasses acarrier wave that encodes a data signal.

Objects, methods, inline caches, cache states and other object-orientedcomponents may be stored in the non-volatile storage 756, or writteninto memory 752 during execution of, for example, an object-orientedsoftware program. In this way, the components illustrated in, forexample, FIGS. 1-6 can be instantiated on the computer system 740.

The computer system 740 is one example of many possible computer systemswhich have different architectures. For example, personal computersbased on an Intel microprocessor often have multiple buses, one of whichcan be an I/O bus for the peripherals and one that directly connects theprocessor 748 and the memory 752 (often referred to as a memory bus).The buses are connected together through bridge components that performany necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be usedwith the present invention. Network computers do not usually include ahard disk or other mass storage, and the executable programs are loadedfrom a network connection into the memory 752 for execution by theprocessor 748. A Web TV system, which is known in the art, is alsoconsidered to be a computer system according to the present invention,but it may lack some of the features shown in FIG. 8, such as certaininput or output devices. A typical computer system will usually includeat least a processor, memory, and a bus coupling the memory to theprocessor.

In addition, the computer system 740 is controlled by operating systemsoftware which includes a file management system, such as a diskoperating system, which is part of the operating system software. Oneexample of an operating system software with its associated filemanagement system software is the family of operating systems known asWindows® from Microsoft Corporation of Redmond, Wash., and theirassociated file management systems. Another example of operating systemsoftware with its associated file management system software is theLinux operating system and its associated file management system. Thefile management system is typically stored in the non-volatile storage756 and causes the processor 748 to execute the various acts required bythe operating system to input and output data and to store data inmemory, including storing files on the non-volatile storage 756.

Some portions of the detailed description may be presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that these and similar terms are tobe associated with the appropriate physical quantities and are merelyconvenient labels applied to these quantities. Unless specificallystated otherwise as apparent from the following discussion, it isappreciated that throughout the description, discussions utilizing termssuch as “processing” or “computing” or “calculating” or “determining” or“displaying” or the like, refer to the action and processes of acomputer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

The present invention, in some embodiments, also relates to apparatusfor performing the operations herein. This apparatus may be speciallyconstructed for the required purposes, or, advantageously, it maycomprise a general purpose computer selectively activated orreconfigured by a computer program stored in the computer. Such acomputer program may be stored in a computer readable storage medium,such as, but is not limited to, any type of disk including floppy disks,optical disks, CD-roms, and magnetic-optical disks, read-only memories(ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic oroptical cards, or any type of media suitable for storing electronicinstructions, and each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the methods of some embodiments. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language, and variousembodiments may thus be implemented using a variety of programminglanguages.

FIGS. 9A, 9B, 9C, and 9D depict flowcharts according to embodiments.FIG. 9A depicts a flowchart 900A of a process according to anembodiment. The flowchart 900A starts at block 902 where identical codefragments in one or more modules are detected. The modules, in thiscase, may include programs, procedures, functions, methods, objects,method objects, blocks, or some other data structure. A code fragment isidentical to another code fragment if a series of associatedinstructions are identical. A determination as to whether code fragmentsare identical may be accomplished by analyzing the runnable codeassociated with the respective code fragments. If the code fragmentsinclude a sequence of identical instructions, then at least a part ofthe code fragments may be referred to as identical to one another.

In an embodiment, the flowchart 900A continues at block 904 where asingle code fragment that is identical to the identical code fragmentsis presented at runtime. Typically, a code fragment is presented atruntime by loading the code fragment into memory, such as RAM. A codefragment that has been presented may be executed by a processor that iscoupled to the memory.

In an embodiment, the flowchart 900A continues at block 906 where thesingle code fragment is shared among the one or more modules, then theflowchart 900A ends. In an embodiment, the sharing may involve sharing acomplete method or a block. In another embodiment, the sharing mayinclude referencing the single code fragment using pointers. Forexample, the objects associated with each of the identical codefragments may be pointed toward a method object. In an embodiment, theflowchart 900A may be carried out sequentially without user involvement.

FIG. 9B depicts a flowchart 900B of a process according to anembodiment. FIG. 9B is intended to depict an example of the treatment ofnew code fragments in a system capable of dynamically sharing codefragments. The flowchart 900B starts at block 912 where new code isreceived from a server.

In an embodiment, the flowchart 900B continues at decision point 914where it is determined whether a sharable code fragment is identical toa code fragment in the new code. If it is determined that the sharablecode fragment is identical to the code fragment in the new code (914-Y),then the flowchart 900B continues at block 916 where the code fragmentin the new code is replaced with a reference to the sharable codefragment, then the flowchart 900B ends. If it is determined that thesharable code fragment is not identical to the code fragment in the newcode (914-N), then the flowchart 900B continues at block 918 where thecode fragment in the new code is saved for comparison against codefragments from future new codes, then the flowchart 900B ends.

FIG. 9C depicts a flowchart 900C of a process according to anembodiment. FIG. 9C is intended to depict an example of introducing newcode to a system that includes a code fragment database. The flowchart900C starts at block 922 where a code fragment database is maintainedwith a list of first code fragments. The listed code fragments may bemaintained by, for example, a code server.

In an embodiment, the flowchart 900C continues at block 924 where a setof code fragments is introduced. The set of code fragments may beintroduced by, for example, downloading a program or dynamicallyuploading code at runtime.

In an embodiment, the flowchart 900C continues at block 926 where, for asubset of the set of code fragments that are identical to a listed codefragment, a reference to one of the list of first code fragments issubstituted for the code fragment itself. In this way, the listed codereferences can be shared by, for example, new code that includesidentical code references.

In an embodiment, the flowchart 900C continues at block 928 where, for asubset of the set of code fragments that are not identical to any of thelisted code fragments, the code reference is added to the code fragmentdatabase. In this way, the code fragment database remains up-to-datebased on the latest code fragments. After block 928, the flowchart 900Cends.

As used herein, identical runnable code fragments may be derived fromsemantically equivalent source code fragments (and it is notparticularly relevant whether semantically-equivalent source codefragments are also syntactically identical because it is thefunctionality of the runnable code fragment that is of consequence). Itmay be noted that it is possible for non-equivalent source code to havesource code fragments that, when translated into runnable code, areidentical.

While this invention has been described by way of example in terms ofcertain embodiments, it will be appreciated by those skilled in the artthat certain modifications, permutations and equivalents thereof arewithin the inventive scope of the present invention. It is thereforeintended that the following appended claims include all suchmodifications, permutations and equivalents as fall within the truespirit and scope of the present invention; the invention is limited onlyby the claims.

1. A process, comprising: detecting identical code fragments in one ormore modules; presenting at runtime a single code fragment that isidentical to the identical code fragments; and automatically sharing thesingle code fragment among the one or more modules.
 2. The process ofclaim 1, wherein the modules include objects.
 3. The process of claim 1,wherein said detecting identical code fragments includes analyzingrunnable code.
 4. The process of claim 1, wherein said automaticallysharing the single code fragment includes sharing a complete method. 5.The process of claim 1, wherein said automatically sharing the singlecode fragment includes sharing a block.
 6. The process of claim 1,wherein said automatically sharing the single code fragment involvesreferencing the single code fragment using pointers.
 7. The process ofclaim 1, wherein said single code fragment includes a method object, andwherein said automatically sharing the single code fragment includespointing objects associated with each of the identical code fragments tothe method object.
 8. The process of claim 1, wherein said detectingidentical code fragments, presenting the single code fragment atruntime, and automatically sharing the single code fragment occursequentially without user involvement.
 9. The process of claim 1,further comprising: receiving new code from a server; determiningwhether the single code fragment is identical to a code fragment in thenew code; replacing the code fragment in the new code with a referenceto the single code fragment if it is determined that the single codefragment is identical to the code fragment in the new code; and savingthe code fragment in the new code for comparison against code fragmentsfrom future new codes if it is determined that the single code fragmentis not identical to the code fragment in the new code.
 10. The processof claim 1, further comprising: maintaining a list of first codefragments, including the single code fragment, in a code fragmentdatabase; introducing a set of second code fragments, each of which areidentical to a code fragment in the code fragment database, and a set ofthird code fragments, none of which are identical to a code fragment inthe code fragment database, by: substituting a reference to one of thefirst code fragments for each of the set of second code fragments;adding each of the set of third code fragments to the code fragmentdatabase.
 11. The process of claim 1, further comprising dynamicallyuploading code at runtime.
 12. The process of claim 1, furthercomprising: writing source code of a program in a programming language;translating the source code into runnable code; and providing therunnable code as at least one module of the one or more modules.
 13. Theprocess of claim 12, wherein said executing the runnable code includesexecuting the runnable code using a virtual machine.
 14. A system,comprising: a code fragments database that includes a plurality of codefragments; and a code server configured to receive requests for aprogram and provide references to one or more of the plurality of codefragments in the code fragments database, wherein the one or more of theplurality of code fragments are associated with the requested program.15. The system of claim 14, wherein the code server is furtherconfigured to detect identical code fragments in one or more objects.16. The system of claim 14, wherein the code server is furtherconfigured to download the program and update the code fragmentsdatabase in accordance with code fragments in the program.
 17. Thesystem of claim 14, wherein the code server is further configured tobuild and maintain the code fragments database.
 18. The system of claim14, further comprising a developer I/O module configured to provide newcode fragments to the code server, wherein the code server is furtherconfigured to update the code fragment database according to the newcode fragments.
 19. A system, comprising: a first object, including areference associated with a first named method; a second object,including a reference associated with a second named method; and amethod object, wherein the reference associated with the first namedmethod and the reference associated with the second named method arepointers to the method object.
 20. The system of claim 19, wherein thefirst object and the second object are associated with differentclasses.